如何找出假設、限制與例外情況？

昨天延續營運後台的例子，談到批次重新處理訂單時，需要核對庫存服務的容量，確認正常訂單與批次作業能否一起滿足服務要求。

假設團隊評估後，決定讓批次工作先排隊，再以受控的速率處理。營運人員可以一次送出多筆訂單，稍後查看逐筆結果。

流程看起來很完整：勾選、送出、排隊、處理、顯示結果。但接手實作時，還有一個值得確認的問題：勾選當下符合處理條件的訂單，輪到它執行時，還符合嗎？

這中間可能只隔幾秒，也可能因為積壓而隔了幾分鐘。對程式來說只是多了一段等待，對訂單來說，卻足夠發生其他事情。

排進佇列的時候，世界沒有跟著暫停

假設一筆訂單已經查明庫存未扣減，依現有規則允許補送。營運人員在後台勾選它，送出批次工作。

但在這筆工作真正執行前，另一位同事已經透過單筆功能完成處理。原本那筆批次工作接著被取出，如果直接拿提交時的資料呼叫庫存服務，就可能再次送出同一筆扣減。

問題出在哪裡？「只有符合條件的訂單才能重新處理」這條規則可能早就寫在文件裡，但實作時，我們把它理解成「送出時檢查一次就好」。

這個理解背後，藏著一個假設：從檢查到執行之間，不會有人改變這筆訂單的狀態。

如果系統原本就有其他處理入口，這個假設便需要證據支持。畫面把按鈕反灰，也只能限制那個畫面上的操作，無法保證另一位使用者或背景工作不會處理同一筆資料。

這也不一定是誰漏寫需求。需求分析時可能已經定義了可操作狀態，直到開發者選擇排隊的實作方式，才讓「何時檢查」變成必須進一步說清楚的問題。

從流程裡找出「我們以為不會發生」的事

我會先沿著既有程式追查：除了這次新增的批次功能，還有哪些地方會處理這筆訂單？單筆按鈕、背景作業或其他入口，是否共用相同的檢查與處理流程？

接著，把提交到執行之間可能發生的變化列出來。先聚焦在會改變處理資格、庫存數量或營運判斷的情況，不需要一開始就列出幾十種災難。

例如，針對這次排隊的設計，可以整理成下面幾個待核對的問題：

表格裡的是待確認的問題，不能直接當成已決定的規格。文件或現有流程已有答案，就記下依據；找不到答案，或不同入口的行為不一致，再帶回團隊討論。

這樣討論會比「例外情況要處理好」具體得多。我們能指出哪一段流程依賴什麼前提，以及前提不成立時，會造成什麼影響。

把例外寫成使用者看得懂的結果

假設團隊確認：已由其他工作完成的訂單，不再執行庫存扣減；原批次仍要保留這筆項目的處理紀錄，讓營運人員知道它為什麼沒有再次執行。

那麼，逐筆結果只提供「成功」與「失敗」，可能就不夠用了。

顯示「失敗」，營運人員可能以為還要再處理；顯示「成功」，又可能讓人以為這次批次執行了扣減。這時可以和團隊確認是否顯示「已由其他作業完成，本次未執行」，並讓使用者查到目前的訂單結果。

同樣地，如果執行時無法確認庫存是否已經扣減，就不應因為這次工作沒完成，而直接顯示成「扣減失敗，可重新送出」。工作本身的執行結果，和庫存那邊實際發生的事情，需要分清楚。

這些文字會影響營運人員下一步怎麼做，因此也是流程的一部分。光是後端避免了重複扣減，使用者卻仍然看不懂結果，原本想減少詢問工程師的目的，可能還是達不到。

規則確認後，還要檢查實作能不能守住

回到前面的例子，開發者可能會想到：「那我執行前再查一次狀態就好了。」

這確實能發現等待期間已經發生的變化，但還要多想一步：如果兩個工作幾乎同時查詢，都看到允許補送，接著各自呼叫庫存服務呢？

因此，執行前重新檢查，是設計的一部分；它本身還不能證明重複操作已被擋住。我們需要檢查現有的工作協調方式，以及庫存服務是否能辨識同一筆操作，確認整段流程如何維持數量與狀態的一致性。具體的並行控制與重試設計，後面的篇章再展開。

今天先把要守住的規則說清楚：同一筆應該只執行一次的庫存扣減，不能因為多個入口或重複提交而多扣一次。 至於使用什麼機制做到，則要對照現有架構、服務能力與驗證結果決定。

驗收時，可以刻意把批次工作停在等待階段，先由單筆功能完成其中一筆，再恢復批次執行，核對庫存異動、訂單狀態與畫面結果。另一個情境則是讓兩個工作同時處理同一筆，確認不會因為都通過檢查，就各自造成一次扣減。

這些測試針對的，就是原本藏在流程裡的假設。若結果不符合預期，也比較容易回頭定位：究竟是規則還沒確認，還是實作沒有守住已確認的規則？

AI可以幫忙找假設，答案仍要有依據

把SRS、狀態定義、批次流程和相關程式碼提供給 AI，可以請它沿著提交到執行的路徑，找出哪些地方依賴資料不變、請求不重複，或下游一定能回覆。

我會希望它把「文件已有規定」「從程式觀察到的行為」和「目前推測的前提」分開列出，並指出對應的文件段落或程式位置。如此才方便核對，也能避免把看似合理的建議直接當成業務規則。

例如，AI建議「遇到狀態改變就跳過」，我們還是要確認哪些狀態可以跳過、跳過後是否需要通知，以及營運人員能否從結果判斷下一步。它可以協助整理選項與測試案例，團隊則要依實際流程確認採用哪個行為。

下一次接到需求時，可以挑一段有等待、跨服務或多個操作入口的流程，試著問：這段程式要正確運作，哪些事情必須一直成立？如果其中一件改變了，系統要怎麼處理，使用者又會看到什麼？

把答案和依據補進設計與驗收條件，原本靠默契支撐的地方，才有辦法一起檢查。

明天回到這個後台功能本身：如果系統已經能查明庫存結果，並安全地接續處理，營運人員還需要一直按「重新處理」嗎？

寫到「排隊時世界沒有暫停」，突然覺得這句話也很適合放在自己的待辦清單上。
早上排好的工作，下午再打開，前面已經多了三件急件。
唯一始終成立的假設，大概是「今天應該做得完」仍然只是假設。